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Abstract 

Transactional memory has arisen as a good way for solving many of the issues of lock- 
based programming. However, most implementations admit isolated transactions only, 
which are not adequate when we have to coordinate communicating processes. To this 
end, in this paper we present OCTM , an Haskell-like language with open transactions over 
shared transactional memory: processes can join transactions at runtime just by accessing 
to shared variables. Thus a transaction can co-operate with the environment through shared 
variables, but if it is rolled-back, also all its effects on the environment are retracted. For 
proving the expressive power of OCTM we give an implementation of TCCS m , a CCS-like 
calculus with open transactions. 


1 Introduction 

Coordination of concurrent programs is notoriously difficult. Traditional fine-grained lock-based 
mechanisms are deadlock-prone, inefficient, not composable and not scalable. For these reasons, 
Software Transactional Memory (STM) has been proposed as a more effective abstraction for 
concurrent programming [1,9,18]. The idea is to mark blocks of code as “atomic”; at runtime, 
these blocks are executed so that the well-known ACID properties are guaranteed. Transactions 
ensure deadlock freedom, no priority inversion, automatic roll-back on exceptions or timeouts, 
and greater parallelizability. Among other implementations, we mention STM Haskell [7], which 
allows atomic blocks to be composed into larger ones. STM Haskell adopts an optimistic eval¬ 
uation strategy: the blocks are allowed to run concurrently, and eventually if an interference is 
detected a transaction is aborted and its effects on the memory are rolled back. 

However, standard ACID transactions are still inadequate when we have to deal with com¬ 
municating processes, i.e., which can exchange information during the transactions. This is very 
common in concurrent distributed programming, like in service-oriented architectures, where 
processes dynamically combine to form a transaction, and all have to either commit or abort 
together. In this scenario the participants cannot be enclosed in one transaction beforehand, 
because transactions are formed at runtime. To circumvent this issue, various forms of open 
transactions have been proposed, where the Isolation requirement is relaxed [2-4,11,13]. In par¬ 
ticular, TransCCS and TCCS m are two CCS-like calculi recently introduced to model communi¬ 
cating transactions [4,5,11]. These calculi offer methodologies for proving important properties, 
such as fair-testing for proving liveness and bisimulations for proving contextual equivalences. 

Now, if we try to implement cross-transaction communications a la TCCS m in STM Haskell 
or similar languages, it turns out that isolated transactions are not expressive enough. As an 
example, let us consider two TCCS m transactions ( c.P ► 0) | ( c.Q ► 0) synchronizing on a 
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channel c. Following the standard practice, we could implement this synchronization as two 
parallel processes using a pair of semaphores cl,c2 (which are easily realized in STM Haskell): 


(c.P ► 0) = atomic { 

up c1 — 1.1 

down c2 — 1.2 
P 


(c.Q ► 0) = atomic { 

down cl — 2.1 
up c2 — 2.2 

Q 


This implementation is going to deadlock: the only possible execution order is 1.1-2.1-2.2-1.2, 
which is possible outside transactions but it is forbidden for ACID transactions 1 . The problem is 
that ordinary STM transactions are kept isolated, while in TCCS m they can merge at runtime. 

In order to address this issue, in this paper we introduce software transactional memory 
with open transactions: processes can join transactions and transactions can merge at runtime, 
when they access to shared variables. To this end, we present OCTM , a higher-order language 
extending the concurrency model of STM Haskell with composable open (multi-thread) trans¬ 
actions interacting via shared memory. The key step is to separate the isolation aspect from 
atomicity: in OCTM the atomic construct ensures “all-or-nothing” execution, but not isolation; 
when needed, isolated execution can be guaranteed by a new constructor isolated. An atomic 
block is a participant (possibly the only one) of a transaction. Notice that transaction merging 
is implicitly triggered by accessing to shared memory, without any explicit operation or a priori 
coordination. For instance, in OCTM the two transactions of the example above would merge 
becoming two participants of the same transaction, hence the two threads can synchronize and 
proceed. In order to prove formally the expressivity of open memory transactions, we define an 
implementation of TCCS m in OCTM , which is proved to correctly preserve behaviours by means 
of a suitable notion of simulation. We have based our work on STM Haskell as a paradigmatic 
example, but this approach is general and can be applied to other STM implementations. 

Lesani and Palsberg [13] have proposed transactions communicating through transactional 
message-based channels called transactional events. These mechanisms are closer to models like 
TransCCS and TCCS m , but on the other hand they induce a strict coupling between processes, 
which sometimes is neither advisable nor easy to implement (e.g., when we do not know all 
transaction’s participants beforehand). In fact, most STM implementations (including STM 
Haskell) adopt the shared memory model of multi-thread programming; this model is also more 
amenable to implementation on modern multi-core hardware architectures with transactional 
memory [8]. For these reasons, in OCTM we have preferred to stick to loosely coupled interactions 
based on shared memory only. 

The rest of the paper is structured as follows. In Section 2 we describe the syntax and 
semantics of OCTM. Some examples are in Section 3. In Section 4 we assess the expressiveness 
of OCTM by providing an implementation of TCCS m , our reference model for open transactions. 
Conclusions and directions for future work are in Section 5. Longer proofs are in the Appendix. 


2 OCTM: Open Concurrent Transactional Memory 

In this section we introduce the syntax and semantics of OCTM , a higher-order functional lan¬ 
guage with threads and open transaction on shared memory. The syntax is Haskell-like (in the 
wake of existing works on software transactional memories such as [7]) and the semantics is a 

small-step operational semantics given by two relations: A- models transaction auxiliary opera- 

1 This possibility was pointed out also in [7]: “two threads can easily deadlock if each awaits some communi¬ 
cation from the other”. 
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Value 


V ::= r | A x.M \ return M \ M »= N \ 

newVar M | readVar r | writeVar r M \ 
fork M | atomic M N | isolated M | abort M | retry 
Term M, N ::= x \ V | MN \ ... 

Figure 1: Syntax of OCTM values and terms. 

tions (e.g. creation) while —» models actual term evaluations. Executions proceeds by repeatedly 
choosing a thread and executing a single (optionally transactional) operation; transitions from 
different threads may be arbitrarily interleaved as long as atomicity and isolation are not violated 
where imposed by the program. 

2.1 Syntax 

The syntax can be found in Figure 1 where the meta-variables r and x range over a given 
countable set of locations Loc and variables Var respectively. Terms and values are inspired to 
Haskell and are entirely conventional 2 ; they include abstractions, application, monadic operators 
(return and »= ), memory operators (newVar , readVar , writeVar ), forks, transactional 
execution modalities (atomic and isolated) and transaction operators (abort and retry). 

Effectfull expressions such as fork or isolated are glued together by the (overloaded) 
monadic bind »= e.g.: 

newVar 0 »= Ax. (fork (writeVar x 42) »= Ay.readVar x) 

whereas values are “passed on” by the monadic unit return. 

Akin to Haskell, we will use underscores in place of unused variables (e.g. A_.0) and M » N 
as a shorthand for M »= A_IV, and the convenient do -notation: 

do{x <— M;N} = M »= (Ax.do {N}) do {M;N} = M »= (A_.do{V}) do{M} = M 

possibly trading semicolons and brackets for the conventional Haskell layout. For instance, the 
above example is rendered as 

do 

x <— newVar 0 
fork (writeVar x 42) 
readVar x 

2.2 Operational Semantics 

We present the operational semantics of OCTM in terms of an abstract machine whose states 
are triples (P; 0, A) formed by 

• thread family (process) P; 

• heap memory 0 : Loc —^ Term; 

• distributed working memory A : Loc —*■ Term x TrName 

where Term denotes the set of OCTM terms (cf. Figure 1) and TrName denotes the set of names 
used by the machine to identify active transactions. 

We shall denote the set of all possible states as State. 

2 We treat the application of monadic combinators (e.g. return) as values in the line of similar works [7]. 
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Threads Threads are the smaller unit of execution the machine scheduler operates on; they 
execute OCTM terms and do not have any private transactional memory. 

Threads are given unique identifiers (ranged over by t or variations thereof) and, whenever 
they take part to some transaction, the transaction identifier (ranged over k , j or variations 
thereof). Threads of the former case are represented by ({M]) t where M is the term being 
evaluated and the subscript t is the thread identifier. Threads of the latter case have two forms: 
<[M > M'; called and ([M > where: 

• M is the term being evaluated inside the transaction k; 

• M' is the term being evaluated as compensation in case k is aborted; 

• N is the term being evaluated as continuation after k commits or aborts. 

Threads with a continuation are called primary participants (to transaction k), while threads 
without continuation are the secondary participants. The former group includes all and only the 
threads that started a transaction (i.e. those evaluated in an atomic), while the latter group 
encompasses threads forked inside a transaction and threads forced to join a transaction (from 
outside a transactional context) because of memory interactions. While threads of both groups 
can force a transaction to abort or restart, only primary participants can vote for its commit 
and hence pass the transaction result to the continuation. 

We shall present thread families using the evocative CCS-like parallel operator || (cf. Figure 2) 
which is commutative and associative. Notice that this operator is well-defined only on operands 
whose thread identifiers are distinct. The notation is extended to thread families with 0 denoting 
the empty family. 

Memory The memory is divided in the heap 0 and in a distributed working memory A. As 
for traditional closed (acid) transactions (e.g. [7]), operations inside a transaction are evaluated 
against A and effects are propagated to 0 only on commits. When a thread inside a transaction 
k accesses a location outside A the location is claimed for k and remains claimed for the rest 
of k execution. Threads inside a transaction can interact only with locations claimed by their 
transaction. To this end, threads outside any transaction can join an existing one and different 
active transactions can be merged to share their claimed locations. 

We shall denote the pair (0, A) by E and reference to each projected component by a sub¬ 
script e.g. E© for the heap. When describing updates to the state E, we adopt the convention 
that S' has to be intended as equal to E except if stated otherwise, i.e. by statements like 
Eg, = E e [r m- M]. 

Formally, updates to location content are defined on 0 and A as follows: 


0[r i-*- M](s) = 



if r = s 
otherwise 


A[r i-)- (M, k)](s) = 


( M,k ) 

A (s) 


if r = s 
otherwise 


for any r,s £ Loc, M £ Term and k £ TrName. Likewise, updates on transaction names are 
defined on E and A as follows: 


E[fc-M] = (0,A[fc->j]) 


(A [fc->j])(r)4 


A(r) 

(■ M,j ) 


if A(r) 
if A(r) 


(. M,l),l ± k 

( M,k ) 


for any r £ Loc, M £ Term and k,j £ TrName. Note that j may occur in A resulting in the 
fusion of the transactions denoted by k and j respectively. Finally, 0 denotes the empty memory 
(i.e. the completely undefined partial function). 
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Thread 

T t :: = 

M, 1 {M >M';TV]) t)fc I (M > M% t k 

Thread family 

P ::= 

T tt \\ ■ ■ ■ \\ T tn 

Expressions 

E ::= 

[-] E »= M 

Processes 

P t ::= 


Transactions 

Tt,k • • = 

([E >M;JVjt,fc I (pEi> 


Figure 2: Threads and evaluation contexts. 


M =£ V V[M] = V 


M -»• V 


(Eval) 


retry »= M — ¥ retry 


(BindRetry) 


return M »= TV ->• ATM 
abort TV »= M -A abort TV 


(BindReturn) 


(Bind Abort) 


Figure 3: OCTM semantics: rules for term evaluation. 


Behaviour Evaluation contexts are shown in Figure 2 and the transition relations are presented 
in Figures 3, 4, 5. The first (cf. Figures 3) is defined on terms only and models pure computations. 

In particular, rule (Eval) allows a term M that is not a value to be evaluated by an auxiliary 
(partial) function, V[M\ yielding the value V of M whereas the other three rules define the 
semantic of the monadic bind. The transition relation modelling pure computations can be 
thought as accessory to the remaining two for these model transitions between the states of the 
machine under definition. 

Derivation rules in Figure 4 characterize the execution of pure (effect-free) terms, forks and 
memory operations both inside, and outside of some transaction; Derivation rules in Figure 5 
characterize auxiliary operations for transaction management (e.g. creation) and their coordina¬ 
tion (e.g distributed commits). Note that there are no derivation rules for retry. In fact, the 
meaning of retry is to inform the machine that choices made by the scheduler led to a state 
from which the program cannot proceed. From an implementation perspective this translates 
in the transaction being re-executed from the beginning (or a suitable check-point) following a 
different scheduling of its operations. 

We shall describe now a representative subset of the derivation rules from Figures 4 and 5. 

Reading a location falls into four cases depending on the location being claimed (i.e. occurring 
in A) and the reader being part of a transaction. The rule (ReadP) characterize the reading of 
an unclaimed location from outside any transaction; the read is performed as expected leaving 
it unclaimed. Rule (ReadT) describes the reading of an unclaimed location r by a thread 
belonging to some transaction k; the side effect of the reading is r being claimed for k. Rules 
(ReadMerge) and (ReadJoin) cover the cases of readings against claimed locations. In the 
first scenario, the reading thread belongs to a transaction resulting in the two being merged, 
which is expressed by renaming its transaction via a substitution. In the remaining scenario, 
the reading thread does not belong to any transaction and hence joins the transaction k which 
claimed the location. The newly created participant does not have any continuation since the 
whole term is set to be executed inside k; any other choice for splitting the term singling out 
a compensation would impose an artificial synchronization with the transaction commit. For a 
counter example, consider executing only the read operation inside the transaction and delaying 
everything after the commit; then concurrency will be clearly reduced. Because of the same 
reasoning, the whole term M is taken as the compensation of the participant. 

Transactions are created by rule (Atomic); threads participating in a transaction are non- 
deterministically interleaved with other threads. The stronger requirement of isolation is offered 
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M N 


(TermP) 


M -»• N 


<Pt[M] ||P;S)->(P t [iV] ||P;E) <T*, fc [M] || P; E)-> <T t , fc [A] ||P;E) 

t' ^ threads(P) t ^ t' 


(TermT) 


s t [fork M] || P;E) -> (P t [return t 7 ] || 
t' threads(P) t ^ t' 


P; E) 


(ForkP) 


(Tt,fe[f ork M] || P;E) -t (T t>fe [return t'] || {M [> return])^*, || P; E) 
threads(T tl || • •• )| T tn ) = {ii,... ,i n } 
r ^ dom(£e) U dom(EA) Eq = £©[r | —t Af] 


(ForkT) 


(P t [newVar M] || P;E) —> (P t [returnr] || P;E') 
r ^ dorn(Ee) U dom(EA) E A = (M, fc)] 

(T tifc [newVar M] || P; £} -> (T tjfc [return r] || P; £') 
r ^ dom(SA) Ee(r) = M 
(P t [readVar r] || P;E) —> (Pt [return M] || P; E) 
r ^ dom(SA) Ee(r) = M £ a = £a[f (M, fc)] 


(NewP) 


(NewT) 


(ReadP) 


(Tt,fe[readVar r] || P; E) - 
M = EfreadVar r] 


• (T t)fc [return M] || P; E') 
Sa (r) = (M',fc) 


(ReadT) 


(M, || P; E) -> (([E [return M'] > XM} t>k || P; E) 
E A (r) = (. M,j ) £' = E[fc j] 


(Tt,fe[readVar r] || P; E) -> (T tJ [return M\ || P[k H> j}\ E') 
r ^ dom(EA) E©(r) = -/V Eg, = £©[r >->• M] 


(ReadJoin) 


(ReadMerge) 


(P t [writeVar r M ] || P; E) —> (P t [return ()] || P; E') 
r £ dom(EA) E©(r) = N E'a = Sa [r>-t(M,k)] 


(WriteP) 


(Tf,fe[writeVar r M] || P; E) -> (T t , fe [return ()] || P; £') 

M = E[writeVar r M'\ Ea( r) = (M", k ) £ a = Ea[f h t (M 7 , fc)] 


(WriteT) 


(Mt I! ^5 S) -> (([E[return ()] > \-M]) t , k || P; £') 

EaW = (N,j) £' = £ [k^j] E' a = E a 


(Write Join) 


(T t) fe[writeVar r M] || P;E) — > (Ttj [return ()] || P[k Ht j]; £'} 
Figure 4: OCTM semantics: rules for —>. 


(WriteMerge) 


by rules (IsolatedP) and (IsolatedT), whose premises forbid thread or transaction creation. 

Committing or aborting a transaction require a synchronization of its participants. In 
particular, an abort can be read as a participant vetoing the outcome of the transaction; 
this corresponds to (RaiseAbortI) and (RaiseAbort2). The information is then propa¬ 
gated by (AbBroadcast) and (TrIgnore) to any other participant to the transaction being 
aborted; these participants abort performing a transition described by either (SigAbortI) or 
(SigAbort2). 

3 Examples 

In this section we provide some short examples to illustrate the use of OCTM and how standard 
STM behaviour can be recovered in OCTM thanks to the isolated construct. In Section 4.2 
we will give an extended example by providing a translation of TCCS m into OCTM. 
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k transactions(P) 


(([atomic M N »= N% II P\ £> <([M > TV; N%, k || P; E) 

(([M]) t ; E) -P (([return TV]) t ; E') 


(Atomic) 


— (IsolatedP) 


(Pt [isolated M]; E) —> (P t [return TV]; E') 
op £ {abort, return} (<[M > return)^*,; E) — >* (([op TV > return)^*; E') 


(T t> fe[isolatedM];E) -)• (T tjfc [°p TV];E') 

T,' A = clean(/c, Ea) 

(([abort M > TV; N%, k ; E) «[TV(M) »= N%; S') 

E^ = clean(fc, Ea) 


(IsolatedT) 


(RaiseAbortI) 


(([abort M > E) (tfTV(M)D t ; S') 

E^ = clean(fc, Ea) 

m > TV; TV']) t , fc ; E) (([TV(M) »= TV'),; E'> 

E^ = clean(fc, Ea) 


(RaiseAbort2) 

— (SigAbortI) 


(([M > E) (tfTV(M)J t ;E') 


(SigAbort2) 


(P; E) (P' ; S') (Q; E) (Q' ; S') 

(p || Q;E) -^(P' II Q'\ S') 


(AbBroadcast) 


Eq = commit(fc, Eq, Ea) E^ = clean(fc, Ea) 
(([return M > TV; TV'jb^; E) AA* (([return M »= TV'])*; E') 
Eq = commit(fc, Eq, Ea) E^ = clean(fc, Ea) 


(COMMITl) 


((M>TV]) t>fc ;E>^<([M]) t; E') 
(P;S)-^(P';S') (Q ; e)^4(Q';S') 
(P || Q;E)^>(P' || Q';E'> 


(Commit2) 


(CoBroadcast) 


(P; E) —* (P 7 ; E 7 ) transactions^) ^ transactions(Q) 


(P || Q;E) A(P' || Q;E) 


clean(fc, A)(r) A 


1 if A(r) = (M, fc) 


commit(fc, 0, A)(r) A 


(TrIgnore) 


M if A(r) = (M, fc) 


0(r) otherwise 


A(r) otherwise 

transactions(([M]) t ) = 0 transactions(([M >M';TV])t ) fc) = {k} transactions] ([M t>TV])t,fc) — {k} 
transactions(T tl || ■ ■ ■ || T tn ) = |^J transactions}! 1 ^) 


l<i<n 


Figure 5: OCTM semantics: rules for 


3.1 MVars 

One of the basic constructs offered by Concurrent Haskell are MVars [10] i.e. mutable locations 
that are either empty or contain a value of the given type parameter. Interaction with these 
structures is based on two fundamental operations: putMVar which fills an MVar if it is empty 
and blocks otherwise, and takeMVar which empties an MVar if it is full and blocks otherwise. 
In [7] MVars are implemented on top of TVars (i.e. STM Haskell transactional locations). 
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Following [7] an MVar of type a is implemented on top of a OTVar (our transactional locations 
i.e. any r £ Loc) holding a value of type Maybe a; this is a type that is either an empty value 
(Nothing) or actually holds a value of type a (e.g. Just 42). Thus, the definition of the type 
MVar a is the following: 

type MVar a = OTVar (Maybe a) 

and its two constructors for creating an empty and a full location are: 

newEmptyMVar = newVar Nothing 
newMVar x = newVar (Just x) 

The definition of the two basic operations is precisely the same appearing in [7] except for the 
added isolated construct for enforcing isolation. 

takeMVar v = isolated do 
v <— readVar v 
case v of 

Nothing —> retry 
Just x —> do 

writeVar x Nothing 
return x 

3.2 Transactional RPC 

MVars can be used as simple directional channels with takeMVar and putMVar as receive and 
send. Then a bidirectional channel for a remote procedure call is easily implemented using a pair 
of MVars 

type RPC a b = (MVar (Corid, a), MVar (Corid, b)) 

where a and b are the types of the request and response exchanged and Corid is a suitable type 
providing a correlation identifier for relating a request to its response. 

Before we introduce the skeleton and stub let us define a conditional variation of the takeMVar 
accepting a boolean predicate p and such that it empties the given MVar v only if the contained 
value satisfies p and blocks (issue a retry) otherwise. 

takeMVarlf p v = isolated do 
v <— readVar v 
case v of 

Nothing —> retry 
Just x — » do 
if p x then 

writeVar x Nothing » return x 
else 
retry 

The conditional version of takeMVar allows us to take a response only if we know its correlation 
identifier and hence the call is simply: 

rpcCall (.req, res ) data = do 
c <r- newCorrelationld 
putMVar req (c, data ) 
r takeMVarlf (c == fst) res 

return (snd r) 


putMVar v y = isolated do 
v <— readVar v 
case v of 

Nothing —> writeVar y Nothing 
Just _ —> retry 



where fst and snd are the first and second projections respectively. Symmetrically, to provide 
the rpc we just need to take a request from the MVar req and put its response in res using the 
same correlation identifier: 

rpcServe (req, res) data = do 
q <— takeMVar req 
a C— doSomething (snd q) 
putMVar res (fst q, a) 

If any of the two parties happens to be partaking a transaction the rpc results in the other joining 
the transaction effectively rendering the rpc transactional. 

The above example is quite simplified (e.g. requests could have been handled by a buffer, and 
the structure of (req, req) should be hidden to the user) but serves the purpose of illustrating 
the difference between OCTM and STM. handled by a buffer, and the structure of (req, req) 
should be hidden to the user) but serves the purpose of illustrating the difference between OCTM 
and STM. In fact, the above implementation allows the call to happen inside a transaction 
without resulting into a lock as in the case of STM since isolation will prevent the serving thread 
to join and provide a response. 

4 Expressiveness of OCTM 

In order to assess the expressive power of OCTM , in this Section we prove that it can be used 
to implement TCCS m , a formal model for open transactions [11]. We proceed as follow: first, in 
Subsection 4.1 we recall TCCS m ; then, the translation of TCCS m processes into OCTM states 
is defined in Subsection 4.2; this translation is proved to be correct in Subsection 4.3. 

4.1 TCCS m : CCS with open transactions 

TCCS m [11] is a CCS-like calculus with open flat can synchronize even when belonging to 
different transactions, which in turn are joined into a distributed one. We refer to [11] for a 
detailed description of TCCS m . transactions: processes can synchronize even when belonging 
to different transactions, which in turn are joined into a distributed one. We refer to [11] for a 
detailed description of TCCS m . 

The syntax of TCCS m is defined by the following grammar 

P ::= V'Lpp.C | UtoT \P\L\X\ /z. X.P | (P 1 ► P 2 ) \ ((P 1 > k P 2 » | co.P (1) 

where a, ::= a \ a | r, a ranges over a given set of visible actions A, L over subsets of A and the 
bijection ( T ) : A —> A maps every action to its coaction as usual. The calculus extends CCS with 
three constructs which represent inactive transactions, active transactions and commit actions 
respectively. Transactions such as ((.PiOfcPj)) are formed by two processes with the former being 
executed atomically and the latter being executed whenever the transaction is aborted, i.e. as 
a compensation. Terms denoting active transactions expose also a name (k in the previous ex¬ 
ample) which is used to track transaction fusions. For instance, consider the process denoted 
by ((Pi >j P 2 )) | ((Qi > k Qi )) where Pi and Q\ synchronize on some a € A; the result of this 
synchronization is the fusion of the transactions j and k i.e. ((P{ P 2 )) | ((Q-] >i Q 2 )). The fusion 
makes explicit the dependency between j and k introduced by the synchronization and ties them 
to agree on commits. In this sense, P[ and Q[ are participants of a distributed transaction [6]. 

As in [11] we restrict ourselves to well-formed terms. Intuitively, a term is well-formed if active 
transactions occur only at the top-level and commit actions occur only in a transaction (active 
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C b P : t 


?bP:p ?hP:p 
?|- P : t <; b co .P : c g b P\L : r 
<r[X : p] h P : p ?[X : c] h P : c 
^hX: <r(A") c P pX.P : p c h pX.P : c 
Vi <r h Pi : p oti.Pi \ c ch?:c ?hQ:p 

S I- Z) oh.P i : p ? h Z oii.Pi : c ? h ((P> fc Q)) : t 


Vi ? h Pi : t 

? i- n Pi -t 

g\~ P : c g\~ Q : p 
<T h (P^ Q) : p 


Figure 6: Simple types for TCCS m . 


or inactive). To this end we introduce a type system for TCCS m , whose rules are in Figure 6. 
Terms that cannot occur inside a transaction have type t, terms that cannot occur outside a 
transaction have type c, and terms without such restrictions have type p; r ranges over types. 

Definition 1 (Well-formed TCCS m terms). A TCCS m term P, described by the grammar in 
(1), is said to be well-formed if, and only if, 0 b P : t. Well-formed terms form the set Proc. 

The operational semantics of well-formed TCCS m terms is given by the SOS in Figure 7 
(see [11] for further details). The reduction semantics is given as a binary relation —>• defined by 

P —> Q P ^aQVP Q. 

The first case is a synchronization between pure CCS processes. The second case corresponds 
to creation of new transactions and distributed commit or abort (/3 G (new/c, cofc, abfc}). The 
third case corresponds to synchronizations of processes inside a named (and possibly distributed) 
transaction. Notice that by (TSync) transaction fusion is driven by communication and that 
by (TSum) any pure CCS process can join and interact with a transaction. 

4.2 Encoding TCCS m in OCTM 

In this section we define the translation from TCCS m processes to OCTM states. To this end, 
we have to implement transactions and CCS-like synchronizations using shared transactional 
variables and the atomic and isolated operators. 

Synchronization is implemented by means of shared transactional variables, one for each 
channel, that take values of type ChState (cf. Figure 9); this type has four constructors: one 
for each of the three messages of the communication protocol below plus a “nothing” one pro¬ 
viding the default value. Let t\ and t 2 be the identifiers of two threads simulating a.P and a.Q 
respectively. The protocol is composed by the following four steps: 

1. t\ checks whether the channel is free and writes on the transactional variable modelling 
the channel a a nonce tagged with the constructor Ml; 

2. t .2 reads the variable for a and accepts the synchronization offered by the challenge (Ml 
np) adding a fresh nonce to it and writing back (M2 np nq); 

3. t\ reads the answer to its challenge and acknowledges the synchronization writing back the 
nonce it read tagged with the constructor M3; 

4. t '2 reads the acknowledgement and frees the channel. 
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Figure 7: TCCS m operational semantics. 


Each step has to be executed in isolation with respect to the interactions with the shared 
transactional variable a. 

Nonces are meant to correlate the steps only and hence can be easily implemented in OCTM 
by pairing thread identifiers with counter a la logical clock. If at any step a thread finds the 
channel in an unexpected state it means that the chosen scheduling has led to a state incoherent 
with respect to the above protocol; hence the thread executes a retry. This tells the scheduler 
to try another execution order; by fairness, we eventually find a scheduling such that the two 
processes do synchronize on a and these are the only executions leading to P | Q. The protocol 
is illustrated in Figure 8. If the synchronizing parties are involved in distinct transactions these 
are fused as a side effect of the interaction via the shared variable. 

A choice like X”=i a *-Pi can seen as a race °f threads fi,..., t m , each simulating a branch, 
to acquire a boolean transactional variable l (private to the group). Each t, proceeds as follows. 
First, it checks l and if it is set, it returns void and terminates (another thread has already 
acquired it); otherwise it tries to set it while carrying out cti, i.e. right before executing its last 
step of the communication protocol. If the variable is acquired by another thread while U is 
finalizing cn then tj issues a retry to retract any effect of cq. The OCTM code implementing 
this protocol is shown in Figure 9. 
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a.P 


var a 


MO 


a.Q 


(Ml np) 


(M2 np ny) 


(M3 ny) 


(Ml nx) , 

(M2 nx nq ) }2 


(M3 nq) 
MO 


Figure 8: Implementing TCCS m synchronization. 


Encoding of TCCS m We can now define the encoding 77 : Proc —> State, mapping well-formed 
TCCS m terms to states of the OCTM abstract machine. Intuitively, a process P = m *1 Pi is 
mapped into a state with a thread for each P; and a variable for each channel in P. Clearly a 
state of this form can be generated by a single OCTM term which allocates all variables and 
forks the m threads; we have preferred to map TCCS m terms to OCTM states instead of OCTM 
term for sake of simplicity. 

The map 77 is defined by recursion along the derivation of 0 P P : t and the number m of 
parallel components in P = P,. This is handled by the auxiliary encoding q : Proc x Heap —» 

State (up to choice of fresh names) whose second argument is used to track memory allocations. 
The base case is given by m = 0 and yields a state with no threads i.e. (0, 0, 0 ). The recursive 
step is divided in three subcases depending on the structure and type of Pi (in > 0 ). 

1. If 0 P P\ : c without top-level restrictions (i.e. for no Q and no L = (m,... ,a ra+ i} such 
that each a* occurs in Q the process Pi is structurally equivalent to Q \ L) then 

II S;E) 

where (S; E) = <r(n™=i 1 -Pj+i> ©) is the translation of the rest of P and ti is unique w.r.t. S 
(i.e. ti threads(S)). By hypothesis Pi does not contain any top-level active transaction 
or parallel composition and hence can be translated directly into a OCTM -term 

by means of the encoding g (cf. Figure 10) - g(P) contain a free variable for each unre¬ 
stricted channel occurring in P. 

2. If Pi has a top-level restriction (i.e. Pi = Q \ {aj,..., a n +i}) then 

mZYPi^) — (Si[ri/ai,.. ,r n+ i/a n+ i] || S 2 ; 02[»T, • • •,r n+ i 1-4 MO], 0) 

where (Si; 0i, 0 ) = q(Q, 0) and (S 2 ; 02 , 0 ) = © 1 ) are the translation of the 

unrestricted process Q and the translation of the rest of P respectively, all threads have a 
unique identifier threads(Si) fl threads^) = 0, the heap is extended with n channel vari¬ 
ables fresh (n,..., 7*„+1 ^ dom( 02 )) and known only to the translation of Q. 

3. If Pi = <IQ 1 t>k Q 2 )) is an active transaction then 

©) — ( s co II Sab || Si[r co /co\ II s 2 ;0 2 [n True,r co (->■ MO], 0 ) 

S co = (recv n r co > g(Qi); bang (recv (newVar True) rco)hco,k 
Sab = ([abort () > return]) ta6ifc 
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data Channel = OTVar ChState 

data ChState = Ml Nonce I M2 Nonce Nonce I M3 Nonce I MO 

tau l P = isolated do 
case (readVarZ) of 
False —> return () 

True —> chooseThis Z » P 

chooseThis l = writeVar Z False 

eqOrRetry x y 

| x == y = return () 

I otherwise = retry 

bang x = fork x » bang x 

recv c l P = do 
nq <r- newNonce 
isolated do 

case (readVar 1) of 
False —> return () 

True —> do 
chooseThis l 
case (readVar c) of 

(Ml nx ) —>- writeVar c (M2 nx nq) 

—> retry 
isolated do 

case (readVar c) of 

(M3 ny ) — > eqOrRetry ny nq » writeVar c MO » P 
—> retry 

send c l P = do 
np <— newNonce 
isolated do 

case (readVar Z) of 
False —> return () 

True —> do 
chooseThis Z 
case (readVar c) of 

MO —> writeVar c (Ml np) 

—> retry 
isolated do 

case (readVar c) of 

(M2 nx ny) —> eqOrRetry nx np » writeVar c (M3 ny) 
—> retry 


Figure 9: Encoding channels and communication 


» P 
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0(£™l^)=do 

l <— newVar True 

Vi e (1,..., m} 

fork £(aj, 1, Pi) 

e(UiLo p i) - d ° 

Vi e {0,..., m} 
fork g(Pi) 

g(P\L)± do 

VcGL 

c •<— newVar MO 

e(f) 

0pO 4 x 

e(P) 

g(co.P) = do 

l <— newVar True 
send co l g(P) 


g(g,X.P) = let X = g(P) in 
g{{P*-Q)) = do 

co <— newVar MO 
atomic p g(Q) 
bang psi 
where 
p = do 

e(P) 

fork (abort ()) 
psi 

psi = do 

l <r- newVar True 
recv co l return 

{ recv ctj l g{Pi) if ctj = c 
send oTi l g(Pi) if a* = c 
tau l g(Pi) if on = r 


Figure 10: Encoding TCCS m terms of type c 


where (Si; 0i, 0) = c(Qi, 0), (S 2 ; 02, 0 ) = © 2 ) (like above), the thread S a b 

is always ready to abort k as in (TAb) and S co awaits on the private channel r co a thread 
from Si to reach a commit and, after its commit, collects all remaining synchronizations 
on r co to emulate the effect of (cf. Figure 7). Finally, all threads have to be uniquely 
identified: threads(Si) fl threads^) = 0 and t co ,t a b ^ threads(Si) U threads^) 

Remark 1. The third case of the definition above can be made more precise (at the cost of a 
longer definition) since the number of commits to be collected can be inferred from Q mimick¬ 
ing the definition of . This solution reduces the presence of dangling auxiliary processes and 
transaction fusions introduced by the cleaning process. 

Like g , g(P, 0) contains a free variable for each unrestricted channel in P. Finally, the 
encoding 77 is defined on each P E Proc as: 

f](P) ~ (S[ri/a 1 ,...r„/a„];0[r 1 ,...,r rl 1-4 MO], 0) 

where (S;0,0) = g(P,0), {rq,..., r„} C Loc, and {ai,...,a„} C A is the set of channels 
occurring in P. 

4.3 Adequacy of translation 

In this section we prove that the translation 77 is adequate, in the sense that it preserves the 
observational behaviour of TCCS m processes. More precisely, akin to [12], we define an appro¬ 
priate notion of star simulation S between well-formed TCCS m processes and states of OCTM. 
The basic idea is that a single step of P is simulated by a sequence of reductions of 77 (F), and 
77 (F) does not exhibit behaviours which are not exhibited by F. 
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Definition 2 (Star simulation). A relation S C Proc x State is a star simulation if for all 
(P,(S;£))eS: 

1. for all Q such that P Q or P \ a Q, there exist S', £' such that (S ; £) —t* (S'; £') 
and (Q,(S';£')) €S; 

/or all Q such that P A Q, there exist S’, £' s.t. (S'; £) A* (S'; £') and (Q, (S'; £')) £ S. 

5. /or all S', £' sued that (S; £) —t (S'; £'), there exist Q , S", £" sited that (Q, (S"; £")) € S 
and one of the following holds: 

• P^ a Q or P AA ct Q, and (S'; S') ->* (S"; £") 

• P A e Q and (S'; £') A* (S"; E"). 

where (3-labels of the two transition relations are considered equivalent whenever are both commits 
or both aborts for the same transaction name. We say that P is star-simulated by (S; E) if there 
exists a star-simulation S such that (P, (S; E)) € S. We denote by « the largest star simulation. 

Another technical issue is that two equivalent TCCS m processes can be translated to OCTM 
states which differ only on non-observable aspects, like name renamings, terminated threads, etc. 
To this end, we need to consider OCTM states up-to an equivalence relation = t C State x State, 
which we define next. 

Definition 3. Two OCTM states are transaction-equivalent, written (Si; Ei) =t (S 2 ; £ 2 ); when 
they are equal up to: 

• renaming of transaction and thread names; 

• terminated threads, i.e. threads of one of the following forms: {return M}t, ([abort M])*, 
([return I> return]) tj fe, ([abort > return }t,k, ([psi])*; 

• threads blocked in synchronizations on co variables. 

Definition 4. Let P € Proc be a well-formed process and (S; £) be a state. P is star simulated 
by (S;E) up to = t if (P, (S;£)) e & o 

We are now ready to state our main adequacy result, which is a direct consequence of the 
two next technical lemmata. 

Lemma 1. For all P,Qg Proc the following hold true: 

1. if P (j Q or P AA a Q, there exist S, £ such that ??(P) —>•* (S; £) and (S; £) =t v(Q)i 

2. if P A Q, there exist S, £ such that rj{P) A* (S; £) and (S; £) =t r](Q). 

Proof. See Appendix A. □ 

Lemma 2. For P £ Proc, for all S, £, if rj(P) —> (S; £) then there exist Q,S',T,' such that 
(S'; £') =t g(Q) and one of the following holds: 

• P Q or P AA ct Q, and (S; £) -P (S'; £'); 

• P A e Q and (S; £) A* (S'; £'). 

Proof. See Appendix A. □ 

Theorem 3. For all P £ Proc, P is star simulated by rj(P) up to =*. 
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5 Conclusions and future work 


In this paper we have introduced OCTM, a higher-order language extending the concurrency 
model of STM Haskell with composable open (multi-thread) transactions. In this language, 
processes can join transactions and transactions can merge at runtime. These interactions are 
driven only by access to shared transactional memory, and hence are implicit and loosely coupled. 
To this end, we have separated the isolation aspect from atomicity: the atomic construct ensures 
“all-or-nothing” execution but not isolation, while the new constructor isolated can be used 
to guarantee isolation when needed. In order to show the expressive power of OCTM , we have 
provided an adequate implementation in it of TCCS m , a recently introduced model of open 
transactions with CCS-like communication. As a side result, we have given a simple typing 
system for capturing TCCS m well-formed terms. 

Several directions for future work stem from the present paper. First, we plan to implement 
OCTM along the line of STM Haskell, but clearly the basic ideas of OCTM are quite general 
and can be applied to other STM implementations, like C/C++ LibCMT and Java Multiverse. 

An interesting possibility is to use TCCS m as an exogenous orchestration language for 
OCTM: the behaviour of a transactional distributed system can be described as a TCCS m 
term, which can be translated into a skeleton in OCTM using the encoding provided in this 
paper; then, the programmer has only to “fill in the gaps”. Thus, TCCS m can be seen as a kind 
of “global behavioural type” for OCTM. 

In fact, defining a proper behavioural typing system for transactional languages like OCTM 
is another interesting future work. Some preliminary experiments have shown that TCCS m is 
not enough expressive for modelling the dynamic creation of resources (locations, threads, etc.). 
We think that a good candidate could be a variant of TCCS m with local names and scope 
extrusions, i.e., a “transactional 7r-calculus”. 

Being based on CCS, communication in TCCS m is synchronous; however, nowadays asyn¬ 
chronous models play an important role (see e.g. actors, event-driven programming, etc.). It 
may be interesting to generalize the discussion so as to consider also this case, e.g. by defining 
an actor-based calculus with open transactions. Such a calculus can be quite useful also for 
modelling speculative reasoning for cooperating systems [14-16]. A local version of actor-based 
open transactions can be implemented in OCTM using lock-free data structures (e.g., message 
queues) in shared transactional memory. 
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A Omitted proofs 

Proof of Lemma 1. The proof proceeds by induction on the syntax of TCCS m . We only show 
three cases: 

1. a transition P Q resulting from a synchronization outside a transaction; 

k(r) 

2. a transition P ——> a Q resulting from a synchronization inside a transaction; 

3. a commit transition P Q. 

1 . If P A Q with (Sync) rule, P = Pi | P 2 , Q = Qi | Q 2 , Pi A Qi, P 2 A Q 2 . 

Pi = {{J2T 1 a i-P'i) I P{) \ Pi such that dha* = a and a ^ L 
P 2 = | P 2 ) \ P 2 such that 3j.h, = a and a ^ L 

V{P) =(([return ti]) tl || ([return t lmi } tauml || S[ || 

II dC(ai 5 Isuml 1 r'i)k, 11 ••• 11 m ®mi •> Isuml 5 )])tlm 1 II 

|| ([return Qt 2 || ([return f 2m2 ]) tsum2 || S 2 || 

|| mbl ,lsum2,RZ)Ki II ••• II mbm 2 ,lsum 2 ,R'L 2 )h^(e>,m 

From hypothesis, there exists a thread t\ r £ {tn,..., ti mi } such that 

([p(u r .P r )])f ir — Jrecv a Isumi P r lh,r 
and exists another thread t 2s € {t 2 1 ,..., t 2m2 } s.t. 

([p(a s .P")])« 2 s = ([send a l sum2 R"}t 2 s- 

Isumi and Isumz are locations created by threads t sum i and t sum 2 from the code generated 
by encoding of the sums. 

(• • • || ([recv a l 3U mi g{R' r )])tir II ([send a l sum2 e(P")Ks II ■■*%(&, 0)) 

-)■* (([return || ([return || S[ || 

|| ([return]) tll || • • • || <[Q(R' r )])tir || • • • II {return]) tlmi || 

|| ([return t 2 ])t 2 || ([return i 2 m 2 ])t „ um2 II -$2 II 

|| ([return ])t 21 || • • • || ([p(P")])t 2S || • • • || ([return ]) t2m2 ; (0', 0)) = (5; S) 
where Q'(l sum i) = False, 0'(Z sum2 ) = False 

recv a l SU mi q{R' t ) and send a l sum 2 s(R") can in order execute the isolated blocks, and 
at the end reduce to continuations g{R' r ) and p(P"). 

Other threads forked by threads t surn i,t sum2 can only reduce to return because 0'(! sum i) = 
False and 0'(l SU m2) = False: threads t\ r ,t 2s modified ^-variables through the synchro¬ 
nization code inside isolated blocks. We can observe (5; S) = t rj(Q), in fact Q = {R[ \ 
p [) \ Li | (Rj | P 2 ) \ L 2 , r](Q) = {S q ; £,). 

V(Q) = (([return t\]) tl || ([p(P')]) ti || S[ || 

|| ([return t 2 ])t 2 || (g(Rj )II S 2 ; (Q' q ,(t))) = ( S q ;T, q ) 
where Vc/i £ L\ l±l L 2 . Q' q {ch) = MO 

{S q \Ti q ) and are different only in local variables and for reduced threads, thus 

<P;£)-*7KQ). 
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2 . If P Q with (TSync) rule, P = (P 1 \ P 2 ), Q = (Qi \ Q 2 ), Pi ^^i^k Qi, 


P = {(Pi Ci)) | {P 2 >j C 2 )) and Pi = Ph | • • • | P lmi , P 2 = P 21 | • • • | P 2m2 - 

r?(P) =(([P 1 ' > g(Ci)]) tui || ([P 2 > £>(C 2 )k,i || (b(Pn) > return]) tll> j || ... 

■ ■ ■ || ([recv a l P[ r > return]) tr>i || • • • || {g(P[ mi ) > return]) tlmi . 

■ ■ ■ II (q( P 2 i) > return])i 21ji II ■' • II ([send a 1 P 2 ' s > return]) ts>i ... 

■•■II d£ , (- P 2m 2 ) [>return ])t2 m2> i;(0, A )} 

^*<([Pi'>0(Ci)Dtij II ffi>e(C2)K* II 

■■■ II {P[ r > return]) tr>i || • • ■ || (P^ > return (0, A')) = (S;I!) 


(5;E) = t rj(Q) = 

=V{{{Pll I • • • I Pl'r I • • • I Plmi >k Ci)) | 

|«P 2 l|---|P' s |---|P2 m2 t> fc C 2 ») 

=<([... >e(Ci)k,fc || > e^k,* II 

••• || ([Pi' r > return k,fc || • • • || (P 2s > return])^ >fc ; (Bq, A,)) 

3 Ifp ^Q with (TCo) rule, P = ((P> fc N)) and {{R> k N)) ^ Rf where R' = n™i Ri 

rj{P) =(|recv co l t return > g(N); R^ t ,k || ([return t m t> return]) 4 / jfe || 

|| l[g(Ri) > returnk,fc || • • • || <[g(Rj) > return}^ )fc || ... 

■ ■ ■ || ig{R m ) > return]) tm>fe ; (0, A)) 
where 

A (It) = (True, A;), A(co) = (M0,fc) 

R =bang psi 

3 j G {1, ... , ?n}, Rj = co.R’j, g(Rj) = send co l g(Rj). 

r](P) ->*((recv co l t return > g(N); R} tik || ([return t m > return|| 

|| ••• |j ([send co l tj g(Rj )> return ]) tj>fc || ...;(0,A")) 

At this point threads t, tj can synchronize through co variable and transaction k can com- 
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mit. 


->*({recv co l t return > g(N); bang psi])^*, || 

|| ([return t m > return]) t / >fc || f£>(Pi) > return]) tl)fc || ... 

■ ■ ■ || ([send co l tj g(R' j ) C> return])^. ife || • • • || {g{R m ) > return]) tm>fe ; (0, A")) 
->■* (([return > g(N): bang psi]) tifc || 

|| ([return t m > return } t ’,k || 

|| fp(Pi) C> return]h 1;fc || • • • || f£>(P') > return])^. >fc || . .. 

■ ■ ■ j| <[g(Rm) > return(0, A"')) 

-^4>(fbang psi]) t || ([return || 

II II ••• II Wj)h II I! = (S;E> 

where E = commit(fc, 0, A'") 

(S; E) = t r)(Q), Q = R' = and G {1,..., m} : Rj = /?,' 


r,(Q) = = MRi)K II • • • II W)h II • • • II {g(Rm)h m ^) =t (S; E) 


□ 

Proof of Lemma 2. The proof goes through induction on the semantic of TCCS m . Here we 
show only 3 cases, first when P are two processes that can perform a synchronization outside 
transactions, second P synchronizes inside transactional processes, third a transactional process 
commits. 

1. If P = a.P\ | H.P 2 From ij(P) we can move to another state of the OCTM machine ( S ; E) 
and (S; E) = t rj(Q): 

V(P) =(([returnii]) tl || (recv a n g^Pi)}^ || 

|| ([return t' 2 } t2 II free van £>(P 2 )])t'; (©', 0)) 

-^(freturnt'J^ || fp(Pi)]) t ' l || freturn t' 2 ]) t2 || fe(P 2 )])i'; (©', 0)} = (S;E) 
where ©'(It-J = False, 0'(Zt 2 ) = False 0'(a) = MO 


If P A Q, then Q = Pi | P 2 , r](Q) = (fp(Pi)]) tl || fe(P 2 )])t 2 5 (©«> 0))» we can observe 
(S'; S') r,(Q). 

2. If P = ((a.Pi>j<2i)) | ((a.P 2 t>jQ 2 )), v(P) —> (S; E) —>* (S'; E') the computations are exactly 
the same as the previous point, but all variables are tentative in A. It is easy to see that 

P Q and (S;E) r?(Q). 
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3. If P = {co.P' > k Q)) 


v(P) = 

={{recv co l return > g(Q);bang psi])^- || 

|| ([send co l g(P') > returnJ)^^; (0, A)) 

->(pf > p(Q);bang psi } t>k || 

|| ([send co l g(P') > return(0, A')) = (S; E) 
where A '(np) = nonce ^ 

-P-^4>(([bang psi]) t || ([g(P')]) t ,-, (0', 0)} 

where E' = commit(fc, 0', A') 

= (s’-, S') 

P = « co.P'o k N )) P' = Q, ?? (Q) = (^(P')K;E 9 ), »7(Q) =t (5'; s') 

□ 
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